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INTRODUCTION 


A  complete  software  package  always  includes  documentation. 
Although  its  importance  is  often  overlooked,  documentation  may  be 
the  only  source  of  program  design  information.  Major  tasks  in  the 
software  life  cycle,  such  as  design,  coding,  testing  and 
maintenance,  are  often  performed  by  different  individuals.  Lientz 
and  Swanson  (1979)  found  that,  typically,  only  about  half  of  a 
software  system's  maintenance  personnel  had  been  involved  in  its 
development.  Poor  documentation  techniques  can,  therefore, 
dramatically  increase  labor  costs  throughout  the  labor  intensive 
software  life  cycle  by  making  both  development  and  maintenance  tasks 
more  difficult. 

Recent  research  in  this  area  (Boehm-Oavis ,  Sheppard,  &  Bailey, 
1982;  Sheppard,  Kruesi,  &  Bailey,  in  press;  Sheppard,  Kruesi,  & 
Curtis,  1981)  has  been  directed  toward  determining  performance  on  a 
set  of  software  tasks  as  a  function  of  the  type  of  documentation. 
In  these  studies,  programmer  performance  was  examined  on 
comprehension,  coding,  debugging,  and  modification  tasks  as  a 
function  of  the  type  of  documentation  provided.  The  documentation 
formats  were  constructed  from  the  factorial  combination  of  three 
types  of  symbology  with  three  types  of  spatial  arrangement.  These 
formats  were  chosen  because  they  represent  the  primary  dimensions 
for  categorizing  the  way  in  which  available  documentation  aids 
configure  the  information  they  present  to  programmers  (Jones, 
1979).  The  three  types  of  symbology  in  which  information  was 
presented  consisted  of  normal  English,  abbreviated  English  (such  as 
program  design  language) ,  and  ideograms.  The  spatial  arrangements 
of  the  information  used  in  these  experiments  were  sequential, 
branching,  and  hierarchical.  While  each  of  the  four  tasks  pursued 
in  this  research  produced  slightly  different  results,  there  was  a 
general  trend  towards  the  superiority  of  succinct  symbology  and  a 
branching  spatial  arrangement  in  each. 

The  current  research  extends  the  previous  investigations  on 
purely  sequential  programs  into  the  domain  of  concurrent  programming 
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by  examining  performance  on  a  modification  task.  Concurrent 
processing  refers  to  the  simultaneous  processing  of  two  (or  more) 
portions  of  the  same  program.  Concurrent  processing  may  be  carried 
out  by  separate  processors  in  a  single  computer ,  separate  processors 
in  several  computers  (distributed  processing) ,  or  it  may  be 
simulated  by  time-sharing  within  one  processor  of  a  computer.  The 
use  of  concurrent  processing  in  a  program  presents  a  problem  in 
representing  those  processes  in  the  documentation.  Most  current 
documentation  formats  were  designed  for  sequential  program 
representation,  and  may  not  be  suitable  for  the  representation  of 
parallel  processing.  It  is  especially  important  to  represent  this 
parallelism  because,  when  a  task  is  split  into  parallel  parts,  two 
or  more  of  these  paths  may  need  to  access  the  same  resources.  The 
documentation  should,  therefore,  provide  explicit  information  on  the 
relationships  between  processes.  If  more  than  one  process  requires 
access  to  the  same  piece  of  information,  protection  of  the  data  may 
be  required  to  assure  its  integrity.  Thus,  programs  using 
concurrent  processing  must  be  constructed  and  documented  carefully 
to  ensure  orderly  access  to  and  sharing  of  resources. 

The  investigation  of  documentation  for  concurrent  processing  is 
especially  important  since  this  form  of  processing  is  generally 
considered  to  be  more  complex  than  strictly  sequential  processing 
and  it  is  used  extensively  in  embedded  computer  systems  which  can 
monitor  and  control  a  number  of  hardware  interfaces  simultaneously. 
Examples  of  embedded  applications  include  systems  for  missile 
guidance,  aircraft  flight  control,  and  multiplexing  of  communication 
channels.  The  current  research  will  investigate  the  usefulness  of 
different  forms  of  documentation  for  this  kind  of  processing. 

The  task  chosen  for  this  experiment  was  a  modification  task. 
Recent  reports  have  asserted  that  almost  70%  of  costs  associated 
with  software  are  sustained  after  the  product  is  delivered.  These 
costs  generally  are  spent  in  modifying  the  original  program  due  to 
changing  requirements  and  correcting  errors,  and  these  figures 
suggest  that  even  small  improvements  in  program  maintainability 


could  be  translated  into  substantial  time  and  cost  savings.  For 
this  reason,  it  is  important  to  investigate  modification  performance. 

Also,  making  a  modification  to  an  existing  program  requires 
several  kinds  of  software  skills:  an  understanding  of  how  the 
program  works;  the  ability  to  generate  the  code  required  to  make 
changes;  and  the  ability  to  debug  these  changes.  Thus,  it  is 
important  to  study  the  modification  task;  it  encompasses  more 
general  skills  that  are  required  for  other  software-related  tasks. 

The  previous  research  suggested  that  the  display  of  control  flow 
was  important  in  the  documentation  of  sequential  programs.  While 
the  display  of  control  flow  should  remain  important  in  documenting 
concurrent  processing,  it  may  be  equally  important  to  document  the 
resource  sharing  among  processes.  The  forms  of  documentation  used 
in  this  experiment  highlight  these  different  types  of  information. 
While  all  of  the  documentation  formats  contain  both  control-flow  and 
resource-sharing  information,  the  two  types  of  information  are 
differentially  emphasized.  The  first  form  of  documentation  is  a 
standard  program  design  language  (PDL) .  The  emphasis  in  PDLs  is  on 
the  control  flow  rather  than  on  the  resource  sharing  of  a  program 
and  the  PDLs  use  abbreviated  English  in  a  sequential  arrangement. 
The  second  form  of  documentation  is  a  resource  diagram,  where  the 
emphasis  is  on  providing  information  about  the  sharing  of  resources 
rather  than  on  control  flow.  Resource  diagrams  use  abbreviated 
English  in  the  communication  circles  and  natural  language  in  the 
process  boxes;  their  spatial  arrangement  is  most  similar  to  the 
branching  arrangement  used  in  our  earlier  research.  The  third  form 
of  documentation  combines  both  types  of  information  by  using  Petri 
nets.  Petri  nets  allow  an  equal  emphasis  on  control  flow  and 
resource  sharing.  The  nodes  in  the  diagram  show  which  resources  are 
required  for  a  task  while  the  constrained  language  descriptions 
contain  control-flow  information.  The  Petri  nets  also  use  a  spatial 
arrangement  most  similar  to  our  branching  arrangement. 

The  structure  of  the  problem  solutions  was  also  manipulated  in 
this  research.  Different  design  methodologies  currently  in  use  take 


different  approaches  to  structuring  programs.  While  some 
methodologies  tend  to  focus  on  data  structures  in  decomposing 
problems,  others  focus  on  functional  decomposition.  This  may  have 
an  impact  on  the  effectiveness  of  different  documentation  formats. 
The  research  described  here  examined  the  effectiveness  of  different 
documentation  formats  using  problems  which  were  structured  to 
represent  solutions  which  might  be  produced  by  commonly'-used  design 
methodologies . 


I 

METHOD 

«  ' 

Materials 


Problems.  Three  experimental  problems  and  one  practice  problem 
were  created  for  use  in  this  experiment.  The  experimental  problems 
were  a  message  distribution  system,  an  air  traffic  display,  and  a 
text  search  problem.  The  practice  problem  was  a  message  encryption 
system.  The  algorithms  used  to  solve  the  problems  were  chosen  such 
that  they  each  represented  approximately  the  same  overall  level  of 
control-flow  complexity  (as  indicated  by  the  McCabe  (1976)  metric). 
Each  problem  was  coded  in  three  ways.  One  version  coded  the  problem 

such  that  it  had  a  complex  data  structure  and  a  simple  control  flow; 

one  version  coded  the  problem  such  that  it  had  a  simple  data 

structure  and  a  complex  control  flow;  and  for  one  version,  the  data 
structure  and  control  flow  each  carried  an  intermediate  level  of 
complexity. 

Modifications.  Two  modifications  were  constructed  for  each 
problem.  One  involved  a  change  in  the  data  structure  of  the 
problem;  the  other  involved  a  change  in  the  control  flow  of  the 
problem.  For  example,  the  data-structure  modification  for  the 
message  distribution  program  (shown,  in  the  appendix)  required  the 
programmers  to  change  the  length  of  the  message.  The  control-flow 
modification  for  the  seune  problem  required  programmers  to  change  the 
algorithm  so  that  when  a  message  was  entered  with  a  particular 
message  code,  all  of  the  readers  would  receive  the  message. 

Documentation  formats.  Three  documentation  formats  were  created 
for  use  in  this  experiment:  Petri  nets,  resource  diagrams,  and 

PDLs.  Examples  of  each  of  these  forms  of  documentation  are  shown 
for  all  of  the  problems  in  the  appendix.  In  the  Petri  nets  (based 
on  ideas  in  Peterson,  1981) ,  each  large  box  represents  a  process  in 
the  system.  The  circles  represent  conditions  which  must  be 
satisfied  before  processing  can  continue.  Information  listed  on  the 
lines  between  circles  represent  actions  that  are  being  carried  out 
or  information  that  is  being  passed  between  processes.  In  the 
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resource  diagrams  (based  on  ideas  in  Shaw,  1974) ,  the  boxes 
represent  processes.  The  circles  represent  information  which  is 
being  passed  between  processes,  and  the  arrows  indicate  the 
direction  in  which  information  is  being  passed.  The  PDLs  use 
standard  notation,  except  for  the  use  of  "send"  and  "accept"  which 
were  the  terms  used  to  represent  the  passing  and  receiving  of 
communications  between  and  from  processes. 

Supplemental  Materials.  Each  program  was  accompanied  by  four 
supplemental  materials:  a  program  overview,  a  data  dictionary,  a 
program  listing,  and  a  listing  of  the  expected  output  from  the 
program.  The  program  overview  contained  the  requirements,  a  general 
description  of  the  program  design,  and  the  modification  to  be 
performed  for  each  program.  The  data  dictionary  contained  the 
variable  names,  an  English  description  of  the  variables,  and  the 
data  type  for  each  variable.  The  program  listing  was  a  paper 
printout  of  the  FORTRAN  code  which  was  identical  to  the  code 
presented  on  the  CRT  screen.  The  listing  of  the  expected  output 
provided  the  programmers  with  the  output  expected  from  a  correct  run 
of  the  program;  this  allowed  them  to  determine  where  they  had  gone 
wrong  if  their  modification  to  the  program  did  not  run  correctly. 

Design 

The  experimental  design  used  in  this  experiment  was  a  3x3x3x2 
split-plot  partially  confounded  design  (based  on  Davies,  1956; 
Winer,  1971) .  The  within-sub ject  factors  were  type  of  documentation 
(Petri  net,  resource  diagram,  PDL) ,  problem  (text  search,  air 
traffic  display,  message  distribution) ,  and  problem  structure 
(complex  data  structure,  complex  control  flow,  intermediate).  Type 
of  modification  (data  structure,  control  flow)  was  a  between- 
subjects  variable.  Each  programmer  modified  three  of  the  twenty- 
seven  possible  combinations  of  documentation,  problem,  and  problem 
structure;  each  programmer  made  three  modifications  of  the  same 
type.  For  example,  a  programmer  might  modify  the  data-structure 
version  of  the  text  search  program  using  a  Petri  net,  the  control- 
flow  version  of  the  air  traffic  display  program  using  a  resource 
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diagram,  and  the  intermediate  version  of  the  message  distribution 
program  using  a  PDL.  The  order  in  which  the  programmers  were 
observed  under  each  treatment  condition  was  randomized  independently 
for  each  programmer. 

Participants 

The  participants  in  this  experiment  were  72  professional 
programmers  from  four  different  locations.  All  were  General 
Electric  Company  employees.  The  programmers  averaged  8.4  years  of 
programming  experience  and  were  familiar  with  an  average  of  5.7 
programming  languages.  All  of  the  programmers  had  previous 
experience  with  FORTRAN. 

Procedure 


Prior  to  the  experiment,  the  participants  were  given  a  one-hour 
training  session  in  which  they  were  shown  examples  of  each  type  of 
documentation  format.  The  experimenter  also  described  the  procedure 
for  using  the  text  editor  to  modify  the  programs  during  this  session. 

Experimental  sessions  were  conducted  at  CRT  terminals  on  a  VAX 
11/780,  Each  participant  modified  all  three  of  the  programs,  which 
were  written  in  FORTRAN-77,  using  only  one  of  the  documentation 
formats  for  each.  The  participants  were  first  asked  to  enter  the 
changes  from  the  practice  problem  which  was  used  during  the  training 
session  to  familiarize  them  with  the  operation  of  the  experimental 
system  and  its  editor.  Following  the  practice  program,  the  three 
experimental  programs  were  presented. 

For  each  program,  the  participants  were  asked  to  first  indicate, 
on  the  documentation  format,  the  locations  in  the  program  where 
changes  needed  to  be  made  and  then  to  .  actually  make  the 
modifications  using  the  editor.  An  interactive  data  collection 
system  prompted  the  participants  throughout  the  session.  The  system 
recorded  each  call  for  an  editor  command  (e.g.  ADD,  CHANGE,  LIST,  or 
DELETE).  From  these,  the  overall  time  to  modify  and  debug  the 
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programs  was  calculated  by  sununing  the  times  from  the  Individual 
editing  sessions;  the  number  of  errors  made  was  also  calculated. 
The  time  required  for  compiling,  linking,  and  executing  the  programs 
was  not  included  in  these  measures.  The  programmers  were  required 
to  continue  working  on  a  program  until  it  was  completed 
successfully.  The  programmers  were  allowed  to  take  breaks  between 
programs. 

Following  the  experiment,  the  programmers  completed  a 
questionnaire  about  their  previous  programming  experience.  The 
information  requested  included  number  of  years  of  experience  and 
number  of  programming  languages  known.  The  participants  were  also 
asked  to  choose  which  documentation  format  they  liked  most  and 
least,  and  to  rate  how  much  they  relied  on  each  documentation  format. 


RESULTS 


Modification  Time 

The  participants  required  an  average  of  23  minutes  to  modify 
each  program.  This  represents  the  amount  of  time  studying  the 
program,  deciding  on  the  appropriate  changes  to  make  the  modifica¬ 
tion,  and  using  the  text  editor  (i.e.,  the  total  time  spent  at  the 
terminal  less  the  time  for  compiling  linking,  and  executing  the 
program) . 
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Table  1.  Mean  Time  to  Complete  Modification  Task  (in  Minutes) 

Table  1  shows  the  mean  times  for  each  combination  of  documenta¬ 
tion  format,  program,  and  type  of  modification.  An  analysis  of 
variance  showed  that,  overall,  it  took  programmers  less  time  to  make 
a  data-structure  modification  (21  minutes)  than  it  did  to  make  a 
control-flow  modification  (26  minutes)  (F  (2,64)  *  12.64,  p<.001). 

This  analysis  also  showed  that,  overall,  resource  diagrams  required 
the  least  amount  of  time  (21  minutes),  PDLs  required  an  intermediate 
amount  of  time  (23  minutes) ,  and  Petri  nets  required  the  greatest 
amount  of  time  (26  minutes)  (F(2,95)  ■  7.31,  p<.001).  A  signifi¬ 
cant  interaction  was  also  found  between  problem  and  documentation 
format  (F(4,95)  ■  2.74,  p  <.05).  An  examination  of  the  data 
suggests  that  for  the  message  distribution  and  air  traffic  display 


problems,  there  were  no  significant  differences  in  modification 
times  for  resource  diagreuns  versus  PDLs  or  for  PDLs  versus  Petri 
nets.  There  does  appear  to  be  a  significant  difference  between 
resource  diagrams  and  Petri  nets  for  both  problems,  however.  For 
the  text  search  problem,  the  differences  between  pairs  of 
documentation  formats  all  appear  to  be  significant. 

There  were  also  large  differences  in  the  amount  of  time  required 
to  modify  the  programs  (control  flow  and  data  structure).  The 
message  distribution  program  required  the  least  amount  of  time  to 
modify  (17  minutes) ,  the  air  traffic  display  program  required  an 
intermediate  amount  of  time  (24  minutes)  ,  and  the  text  search 
program  required  the  greatest  amount  of  time  (29  minutes) .  The 
analysis  of  variance  supported  this  conclusion  (F(2,95)  =  32.30, 

p<.001).  This  pattern  of  results  mirrors  the  complexity  ratings  of 
the  programs,  as  measured  by  the  McCabe  metric.  While  the  programs 
were  chosen  to  be  roughly  equal  in  overall  complexity,  there  were 
some  differences  among  their  ratings,  which  followed  the  pattern  of 
the  time  data;  the  message  distribution  program  had  an  overall 
complexity  rating  of  14,  the  air  traffic  display  program  had  an 
average  complexity  rating  of  15,  and  the  text  search  program  had  an 
average  complexity  rating  of  23. 

There  was  no  effect  of  the  structure  of  the  programs  (simple 
control-flow  with  a  complex  data  structure,  intermediate  control 
flow  and  data  structure,  or  simple  data-structure  with  complex 
control-flow)  on  modification  time  (F(2,95)  <  1),  and  it  did  not 
interact  with  any  of  the  other  variables. 

Errors 


For  programs  that  did  not  compile  or  run  successfully  on  the 
first  submission,  the  programmers'  editing  activities  for  subsequent 
submissions  were  analyzed  to  determine  the  number  of  errors.  Table  2 
shows  the  mean  number  of  errors  for  each  combination  of  documenta¬ 
tion  format  and  type  of  modification.  The  number  of  errors  was  low; 
in  addition,  the  majority  of  the  errors  (63%)  were  syntax  errors 
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rather  than  semantic  errors.  (For  this  analysis,  misspellings  of 
variable  names,  starting  a  line  in  the  wrong  column,  and  other  such 
errors  were  categorized  as  syntax  errors.)  Due  to  the  low  number  of 
semantic  errors,  no  further  analysis  of  these  data  was  carried  out. 


MODIFICATION 

DOCUMENTATION  FORMAT 

rnUoLcW 

RESOURCE 

POL 

PETRI 

TOTAL 

MESSAGE 

DISTRIBUTION 

.8 

.9 

.7 

.8 

CONTROL  FLOW 

AIR 

TRAFFIC 

1.2 

1.3 

.8 

1.1 

TEXT 

SEARCH 

1.1 

1.4 

1.7 

1.4 

MESSAGE 

DISTRIBUTION 

1 

0 

.1 

.1 

DATA  STRUCTURE 

AIR 

TRAFFIC 

.4 

1.1 

.6 

.7 

TEXT 

SEARCH 

.  .4 

.7 

.6 

.6 

1  TOTAL 

.7 

9 

.8 

.8 

Table  2.  Mean  Number  of  Errors 
Preferences  for  Documentation  Format 


Across  the  three  problems,  the  programmers  received  each  type  of 
documentation  format.  On  the  questionnaire,  they  were  asked  to 
state  which  documentation  format  was  easiest  to  use  and  which  was 
hardest  to  use.  They  were  also  asked  to  rate  how  much  they  relied 
on  each  version  of  documentation  format  on  a  seven-point  scale  (from 
0  »  not  at  all  to  6  =  constantly  throughout)  .  Tables  3  and  4  show 
the  number  of  people  choosing  each  documentation  format  as  easiest 
or  hardest  to  use  as  a  function  of  type  of  modification  made.  In 
the  control-flow  group,  two  programmers  failed  to  indicate  which 
format  had  been  easiest  to  use;  a  third  programmer  failed  to 
indicate  which  format  had  been  hardest  to  use.  Overall,  seventy-one 
percent  of  the  programmers  chose  the  PDL  format  as  the  easiest  to 
use;  18%  chose  the  Petri  net,'  and  14%  chose  the  resource  diagram. 
The  programmers  were  also  asked  if  they  had  previously  used  any  of 
the  documentation  formats.  Eighty-three  percent  of  the  programmers 
making  a  control-flow  modification  indicated  that  they  had 
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previously  used  a  PDL;  only  53%  of  the  programmers  making  a 
data-structure  modification  had  previously  used  a  PDL.  Three  of  the 
programmers  indicated  that  they  had  previously  used  a  form  of 
resource  diagram;  four  of  the  programmers  had  previously  used  a  form 
of  Petri  net.  Table  5  shows  the  mean  rating  of  how  much  they  relied 
on  documentation  format  for  each  type  of  modification.  For  both 
types  of  modifications/  the  programmers  stated  they  relied  most 
heavily  on  the  PDLs,  and  less  so  on  the  resource  diagrams  and  Petri 
nets. 


MODIFICATION 

DOCUMENTATION  FORMAT 

RESOURCE 

POL 

PETRI 

CONTROL  FLOW 

5 

23 

6 

DATA  STRUCTURE 

6 

27 

3 

Table  3.  Number  of  Times  Documentation  Chosen  as  Easiest  to  Use 


MODIFICATION 

DOCUMENTATION  FORMAT  | 

RESOURCE 

PDL 

PETRI 

CONTROL  FLOW 

11 

5 

19 

DATA  STRUCTURE 

11 

5 

20 

Table  4.  Number  of  Times  Documentation  Chosen  as  Hardest  to  Use 


MODIFICATION 

DOCUMENTATION  FORMAT 

RESOURCE 

POL 

PETRI 

CONTROL  FLOW 

2.4 

3.6 

2.8 

DATA  STRUCTURE 

2.0 

3.3 

1.9 

Table  5.  Mean  Ratings  of  Reliance  Upon  Each  Documentation 
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The  participants  were  asked  the  number  of  years  they  had  been 
programming  and  the  number  of  programming  languages  they  knew.  No 
correlation  was  found  between  years  of  programming  experience  and 
modification  time.  A  low  negative  correlation  (£  =  -0.23,  p<.05) 
was  found  between  number  of  programming  languages  known  and 
modification  time. 


I 
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DISCUSSION 


Substantial  differences  in  completion  time  were  observed  among 
the  three  types  of  documentation  formats.  For  both  kinds  of 
modification  (control  flow  or  data  structure) ,  the  resource  diagrams 
led  to  the  best  performance  while  Petri  nets  led  to  the  poorest 
performance.  This  suggested  that,  unlike  sequential  processes  where 
control-flow  information  was  required,  concurrent  processing 
requires  information  about  interprocess  communications.  Because 
data  structures  are  often  used  to  pass  information  between 
processes,  the  resource  diagrams,  which  highlight  information  about 
communications  between  processes,  also  highlight  data  structures. 
Both  kinds  of  modifications  required  locating  the  particular  data 

structures  that  needed  to  be  changed;  this  probably  accounts  for  the 
fact  that  it  was  easier  to  locate  and  make  modifications  when 

resource  diagrams  were  used.  Two  things  should  be  noted,  though. 
First,  the  data  suggest  that  the  differences  among  documentation 
formats  are  not  very  pronounced  for  all  cases;  the  text  search 
program  provided  the  most  striking  differences.  Second,  the 
modifications  used  in  this  experiment  were  simple  and  did  not 
require  many  control-flow  changes;  this  will  not  always  be  the  case 
with  modifications.  This  suggests  that,  at  least  for  simple 

programs  and  simple  modifications,  it  is  not  crucial  whether 
interprocess  communications  or  control-flow  information  is 
highlighted  in  the  documentation  format.  For  more  complex  problems, 
the  longer  times  required  by  the  Petri  nets  and  PDLs  suggest  that 
when  modifications  are  made,  detailed  control-flow  information  is 
not  necessary,  and,  in  fact,  may  interfere  with  making  the 
modification. 

Differences  were  also  observed  among  the  three  problem  types 
used  in  this  experiment.  The  message  distribution  problem  was 
associated  with  the  shortest  times,  the  text  search  problem  resulted 
in  the  longest  times,  and  the  air  traffic  display  problem  was 

in-between.  This  result  parallels  our  past  experiences  in  finding 
differences  across  problems.  While  the  programs  were  roughly 
equated  in  terms  of  a  common  measure  of  complexity,  they  did  have 
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slightly  different  complexity  ratings,  as  measured  by  the  McCabe 
metric.  The  amount  of  time  required  to  make  modifications  was  found 
to  be  longer  for  the  problems  with  a  higher  complexity  metric, 
suggesting  that  control-  flow  complexity  may  indeed  provide  a  good 
measure  of  psychological  complexity. 

Diversity  of  experience,  in  terms  of  the  number  of  languages 
used,  was  a  better  predictor  of  performance  than  years  of 
experience.  This  result  replicates  results  from  our  earlier 
research  (Sheppard,  Kruesi,  &  Bailey,  in  press;  Sheppard,  Kruesi,  & 
Curtis,  1981;  Sheppard,  Milliman,  &  Curtis,  1979)  and  highlights  the 
importance  of  ensuring  that  programmers  have  an  opportunity  to  gain 
broad  applications  experience  as  part  of  their  professional 
development. 

The  participants'  choices  for  the  easiest  to  use  documentation 
format  and  their  previous  familiarity  with  one  of  the  documentation 
formats  lead  to  an  interesting  observation.  Although,  overall,  68% 
of  the  programmers  had  used  PDLs  before  this  experiment  and  71%  of 
them  chose  it  as  the  easiest  to  use,  the  time  required  to  make  the 
modifications  with  the  PDLs  was  in  between  the  other  documentation 
formats,  for  the  two  types  of  task  modification. 

Taken  as  a  whole,  the  data  suggest  that  the  most  appropriate 
type  of  documentation  for  concurrent  processing  (resource  diagram) 
is  different  than  the  most  appropriate  type  of  documentation  for 
strictly  sequential  processing  (PDL) .  For  modifications  to 
concurrent  processing  programs,  at  least  for  simple  programs  and 
simple  modifications,  it  is  not  crucial  whether  interprocess 
communications  or  control-flow  information  is  highlighted  in  the 
documentation  format.  For  more  complex  problems,  it  would  appear 
that  detailed  control-flow  information  is  not  necessary,  and,  in 
fact,  may  interfere  with  making  the  modification.  These  data  are 
especially  interesting  at  this  time,  when  PDLs  are  becoming  a  de 
facto  standard  in  the  software  industry.  Further,  they  suggest  that 
industry  may  be  preparing  to  adopt,  as  a  standard,  a  documentation 
format  which  will  not  necessarily  provide  them  with  the  greatest 
possible  benefit. 
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APPENDIX  -  DOCUMENTATION  FORMATS 

RESOURCE  DIAGRAMS 
PROGRAM  DESIGN  LANGUAGES  (PDLs) 

PETRI  NETS 
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PROGRAM  DESIGN  LANGUAGES  (PDLs) 
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ono  4CMAM.0CAMP 


tof  in 

ftoot  nauM.p*02uccii 

<ooonotinf  ootton  •ill  oUo«  oooolo  to  fot  into  to#  siitriOwtior  toito#  e 
rwnniftf  too  nClUMjCAOCT  to«k> 
onO  MltMCj)llTWIlVTIOW 


nCStAdC.D!STNt8UT!Qr4 

SZ6NAL  It  (NCU.nCSSA6rffCAC.r«r5A<SC-NCM^.‘?£ACeP 
t««k  nCSSAOC.^ftQOuCCA 

cxcc.to  (MreocK 
nssd.cooc  smiNou  5> 
nCtSAOC  irKtMCit 
9««in 

CfftArctrvCSSACC.Cxcc.  CXCC.:0) 

«•  wlitl*  ^<A««  itttttt  t«i 

<<a»«v«car  nsSS^jCJCO  co 

9P<9«9t  C<tt«f4tor  «*e  *iCS5»»SC>  *e  t«r«tn«l 
««fi4  <NCU  nCStAOC)  to  nCttAdC.CkCC 
t«n«  tnltO.CQOC.  nCSSA6C>  to 
•no  00 

•no  PCatAOC.MOOOCO 

c««k  nCSAAOCjbXCC 
••< loro 

/iCOuCSr  SXdfMC 

to  tNrsco 

ns«e  COOC  flUtNOU  S/ 
nCtSACC  ST«tNC<t  72) 

»04in 

10  «n(lo  (<no«  oil  nCSSA<dC  rOOCPt  &••»  tori»irof»o> ) 

«<«•••  lAffOuCST)  #ro«  nCSSACC.^^'TCOCC^  or  .nCS&*«;£.aCACC9 

i#  (ftCOUCir  •  NCU.nCSSACC)  to  on 

•ceo»«  (nSM.COOC.  nCfiSA«e>  r.>o«  •^fiSAOC.aitO&^^cer  • 

to  •  <no«  ■••ttoio  i««n«i*i«r  n««o«r> 

<$••  nCSSACC.^OtSOuCCP  wontt  «<««eon  '.•r«;f*«4;*i:  ai*  cnocki"g 

V«iwO> 

•  Ito  t*  iHCOUCST  «  OCAO^^SSACC  rn«n 

(<no«  t«r«tnotinf  p)CC5aCC.-CaOCA  0rcc«t«*i/  ;p*n 
tono  ( to.  ^«Md.caK.  nCSSACC'  »e  ncsSocC.rTCACCP 

•  It# 

tono  (tO.<tt«<i«l  toroianotion  n^SC^CdCC:  ncsSAGC  to  nCSSA<iC.'"6>C-2^ 
•no  t# 

•  loo  <ACM87  •  mCW^ACaOCM)  tA«n 

<r#oi— »»r  to«e  #noto#f  nfSiAdC.r CaOCR  it  •etis*> 

•no  il 

•no  Oo 

•no  NISMC.CXCC 

cook  r«tSMCJkCAOCff 
4«eloro 

to  tNTtOCK 

tCAOCR  COOC. nSSC .COOC  3r«iN0<l  « 
nCCMC  STRINQU  72> 

0*4in 

««no  ( NCU.OCAOCff  >  to  nCSSAi^C.exCC 

proiBOt  ( <ooor«t«r  kor  Mt  OCAOCKjCOCO’  to  tor.iti?«a; 

•  o  wnil*  ( <tor«tn«0«on  not  not  •••>■  *^90u*te»o  ay  '*€S4AGC_EkCC> 
tono  (ncAO  ncscAoc)  to  ncssAcejt:<ec 
•<eoft  ( to.  rtCSO.COOC. '•C5SA0C)  *r3»  nCSSnOC.C^CC 
<•••  ik  t«r«inotton  «>oO'k«ttOO  9<i  cnocttn^  nSfO.COOC  v«lwo> 
tk  <  <n««  nottnfo  ono  fcSSO..'*OOC  •  'CAOCA^COOO  ’  ’:non 
«rit«  (nCSSnOC)  to  tor«in«l 
•no  j  0 
•no  Oo 

•no  k«SfAQC.HCAOCR 


k«f  kn 

•tort  kCCCMC.^ffOOgcCR 

^•••noOinf  totkon  «tll  •Uott  ••••l«  to  9«t  mta 
runninf  tn<)  nCSSAOC.I«CAOCl«  t«tk> 

•no  nccfnoc.otsmtflWTtQN 


“h*  aittr^Owcier  tytton.  5 
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4«c l«r« 

«!«••  SIONM.  i«  NCki.'^SiACC. ‘•Cw^fiC^CCf* 

c««k  nCiSAOC.MQOuCCH 
««e l«r« 

**mA6C  «T«tNail  *2- 
CxCC.lD  iNTCaCH 
"«M.:ooc  ariitNOii  9. 

9«9in 

:ii(Ar;(»«MA«:c.cscc.  cxcc.:s 

44  wAtl*  (  <n«t  4«««f«4  >•«  44«r4ter^'* 

•  ra«tt  i\«44f‘4fa^  to 

|V4*«4  (<4«4^0««r  'HCSSai^O  C9 

««n«  >NCW  ««CtSMC>  to  *tCs3A6C^CA£C 

inMO.CQOC.  to  "CS8*CC.CkCC 

•  ft4  40 

0fi4  >«SMC.Ma0«^O 

t««K  nctftAOC^CkCC 

4«<  tOPO 

COM  rLOSiiO)  rsrtnoNCCArrON 
«CAOO«COOCf i  10)  3TlltN<;>t  *9> 

*«ttA6C  smiNGa  ^2> 

•CQocsr  sioNM. 

Nun^flCAOCflt  INfCOCfl 

•  •fin 

10  ^itovo^ 

.o<to«t  (llCM2t)  4fpm  -<SSaCC.so::uCCP  <aSA.^.«CA&Cll 
\*  >«CdUCST  •  nCU.^SSaCC)  tKor 

octfoot  ^^M.coor  ncSSAdC  «<>0<»  ^3£aM_ai»CC.C£^ 

(<rtUO.CQOC  /•  «OOCiOl  tor«iro«to«'  .oivO>  toon 

40  *04  t  •  1  to  ‘AJH  flCACOS 

It  (^Sd.caoc  •  4CACcii.c2C£r  I  t4o«^ 

$CT.)fc0(C0R.^35‘ :  • 

«#A«  (HtM.COOC.  to  ^fiSA6C.eC*CCJt 

0A«  it 

s  OAO  40 

ol«o 

40  40P  f  •  i  to  *«tM.ACAXHPa 
•«T.rw«(COH,ri.asa'- 

40R4  '<4#OClOl  tOPOtAOtlOP  -tSO.CQOO  ■  '^SSA4C  to 

OAO  40 

out  40 

004  \  t 

OUO  it  (RCQUCir  •  nCu^oCaoCR)  t«oA 
Nun.oCAOOa  •  Nun.ocAOCnsM 

occoot  <ff(AOCR.CQOC2^NgH.rCAOC»:  •  ^•'oa  *tcsS*6C.9CACC1i 
40A4  '<no«c  .jnw«04  olo«oAt  9*  ;Ct*^4uSS>  to  '*CS£>m^_ocaO€^ 

ono  i4 

ono  40 

ono  r^SMC.CXCC 
tool  *tCS«*OC.<lCAOO( 
ooelopo 

Cmj\,9  COf*<UNlCATtON^rLikC 
•CAOCR.COOC.  "«UA«C.caOC  srotMO<:  9' 

-^SMC  smiNad  r3) 

tOflA 

•  40<00t  '<00040404  *04  «14  ^CACCI.C^CC)  to  t04«l-O* 

4Of(0  '  NCM^OCAQCP  '  to  MCiSA4»C.CXCC 

4OA0  <IICaOC1I.C3K)  to  *<«SSAOC.C«CC 
occoot  ^COn.^Ld)  «40<0  •<StA6C.CxCC 

40  #04OVO4 

UA I T  ^OH  ,4\.G  <  COW  .^LO » 

occoot  (WMG.CQOC.  ioCSSaGC*  4«*o«  ”CSS*GC.etCC 
it  'WfM^CODC  '•  iooociot  co^AtPotioA  »o»wol  -  '“on 
w4(to  iHCSSAOC)  CO  to4<«in«l 

0140 

out  40 
000  1 4 

0410  00 

0410  *«ffAOC.MCAOCR 


tOf  141 

otoot  4«tMC^«00UCBI 

<00000«|Af  toOtOA  Mill  ollO«  oooolo  tO  fOt  into  t4>0 
fgfi4il4if  too  WKltAGtJttAOCT  eook> 

0410  HtS«AOCj0ttTNStvrt&« 


MESSAGE  DISTRIBUTION  (0) 


35 


progrAM  AIR.TRAFFIC .DISPLAY 
•iPclAra 

tgp*  OB JECT.OESCRIPTOR .RECORD  it  racord 
ID  :  INTEGER 
ALTITUDE  :  INTEGER 
ROW  :  INTEGER 
COLUMN  :  INTEGER 

ALTITUDE.CHANGE.INDICATOR  INTEGCR 
HAZARD  INDICATOR  ;  INTEGER 
OLD.ALT  ;  INTEGER 
•nd  record 

SVNC.SIGNAL.TO.RADAR.MONITQR  COMMLNlCATIQN.rLAG 
tA«k  CONTROL 

<stAr««  up  tho  othor  two  pracas«*«  in  tha  tgttam  and  allowa  tha  sparator  to 
tarminata  tha  ai^atam.  > 
anj  CONTROL 

caak  RADAR.MONITOR 

x'par icdicalli^  landa  a  *ac  of  CBw'£CT_DE3CR IPTOR.RtCCPDa  to  SCRCEN_oPDaTE  ao 
that  it  can  update  tha  air  tra'f'^i-:  diaplag  and  alao  notifiea  tha  SCRCEN. 
UPDATE  procaaa  at  tha  time  it  anould  tarminata  ':rat  it  ahould  tariainaca  > 
and  RADAR.MONITOR 

taak  SCREEN.UPDATC 
declare 

0BJECTS(20)  OBJECT  0E3CR iPTOR.RECCRD 
NUM.OBJECTS  INTEGER 
begin 

do  #oravar 

SET.FLG  <  SYNC .S I GNAL.TO.R AC AT .MON I TOR ) 
accept  (NUM.OBjECTS)  fro«  RADAR.MONITOR 
if  (<and  of  #ila  found  inataad  of  NUM.Q8JECT3> than 
exit  do 
and  if 

do  for  I  ■  1  to  NUM  OBJECTS 

accept  (OBJECTSCin  from  RADAR.MONITOR 
if  (<objact  diaappaarad  from  tcraan>)  than 
<claar  image  of  object  'ram  acraon> 
and  if 
and  do 

do  for  I  •  1  to  NUM.OBJECTS 

if  (-Cnow  objact  on  aeraan>)  than 
{initiaXixa  record  OBJECTOdM 

aloe 

<oava  indicator  of  altitude  change  of  object  in  record  OBJECTS(l)> 
and  if 
and  do 

<chack  whathar  ang  objecta  are  too  cloaa  to  each  other,  aaving  an  indicator 
of  tha  aafatg  of  each  objact  in  tha  OBUECTS  racerda> 

<araaa  tha  acraan  on  tha  diaplag  CRT> 

<far  each  objact  daacribad  bg  OBJECTS,  update  the  object  diaplag  on  the 
diaplag  CRT> 
end  do 

end  8CRESN.UP0ATE 
begin 

atart  CONTROL 
end 
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program  AIR_THA.'*FIC_DISPuAV 
'i«c  lar« 

tgp*  OBJECT  DC5CRIPT0F  TtCOrC  i%  rt-.zn 
ID  INTEGER 
ACTITODE  :  INTEGER 
ROW  INTEGER 
COLUMN  :  INTEGER 

ALTITUDE  change  INDICATOR  INTEiOR 
hazaro.indicator  integer 

•nd  record 

S>  NC  _S  I GNAL_TQ _R  ad  AR  _MaN  I  TOR  C CMHI.  N I C  A T  I  ON  _rL AG 

task  CONTROL 

<«tarts  up  tha  othar  tuio  prciaaaa*  '.n  cha  fi^atam  ar>.  allow*  'rn*  :p4rator  ?s 
tarminata  tha  tgatam.  > 
and  CONTROL 

task  RaDAR.MONITOR 

-Cpariodicallq  land*  a  «*t  of  CBoEC 
that  it  can  updata  tha  air  cra^'^i 
UPDATE  proca**  at  tha  appropriata 
and  RADAR  .MONITOR 

ta*k  SCREEN .UPDATE 
dac lara 

0.0  OBJECT,  NEW  0BJECT(2C.'  CC  jEC'.CESCK  IPTCF  RECCPC 
NUM^OBoECTS  INTEGER 
bagin 

<ara«a  tha  scraan  on  tha  eiipla^  CR~> 
do  loravar 

SET_FLG  ( SYNC  _S  IGNAL.TC  .P  AC  aT  _MCN  I  ~QR 
accapt  (NUM.CBJECTS)  I'rom  RACAR.MCNITCR 
i#  (<and  o#  #ila  Vaund  in*taad  or'  NUM.08oECT3>  ■  Than 
aiit  do 
and  i# 

do  ^or  I  «  I  to  NUM.OEuECTS 

accapt  ( OLD  .OBJECT,  NEW.GBwECT.  from  PACAP.rONITCP. 
if  <<naw  objact  an  *craan>>  than 
Cinitialixa  racord  NEW.CBvEC T • I ) > 
al*a  if  <<obj*ct  diiappaarad  fr:m  scra*n>>  than 
<ciaar  imaga  of  objact  From  icra*n> 
also 

<*av*  indicator  oF  altitud#  ihanga  of  objacT  in  racord  nEU.CSjECT >  : : ^ 

and  if 
and  do 

<chack  whathar  ang  ob  jact*  ara  toe  clo*a  to  aaci  cchar.  <.aving  an  indicator 
of  tha  safatg  of  aach  objact  in  tha  NEW.OBjECTi  r*cdro«> 

<for  aach  objact  bg  daacrioao  NCW.OBjECT*,  updata  cna  objact  tiiplag  or  tha 
di«plag  CRT> 
and  do 

and  SCREEN.UPDATE 

bagin 

atari  CONTROL 

and 


PCSCPIP'FO.R.PEC'.RC*  to  SCPEEN.lFCaTE  *c 
diaplag  -  alic  notifia*  tha  SCREEN, 
tma  that  it  ihculd  tarmiratal- 
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pro9<*a<*  AIR_TRArFIC_OISPLAV 
licclAr* 

0BJECT_0£SCRIPT0R_rEC0R0  it  r«cord 
10  :  INTEGER 
altitude  :  INTEGER 
ROW  INTEGER 
COLUMN  :  INTEGER 

ALTITUDE  CHANGE  INDICATOR  INTEGER 
HAZARO.INOlCArOR  ;  INTEGER 
•nd  record 

SVNC_SICNAL_TQ_RAOAR_MaNITQr  COMMUNICATION. TLAG 
tMtk  CONTROL 

<«t4rt«  up  tfto  othor  two  pracdisoc  in  th«  ere  Allows  th*  cpdrAtcr  to 

torminAto  tfto  sustom.  > 

•nd  CONTROL 

tosk  RADAR  .MONITOR 

•  <por iod leal I14  sonds  «  soc  c:'  QBuECT.0C3CR!PT0R_REC0rDs  to  SCREEN.UPCATE  to 

that  it  can  update  the  air  trariiic  displai^  and  also  notifies  the  SCREEN. 
UPDATE  process  at  the  time  it  sho<jld  terminate  that  it  should  terminate  > 
end  RADAR .MONITOR 

task  SCREEN.UPOATC 
declare 

CURRENT.OBw‘ECTS<aO).  NEXT.0BUECT5i2C:  ;  0BUECT.DE3CR IPTOR .RECORD 
NUM.IN.NEXT  INTEGER 
beg  in 

do  forever  t 

SET  .FLO ( SYNC  JS I ONAL.TO  _R  AOAR  _MON I TOR ) 
accept  (NUM.IN.?dEXT)  Trom  RAOaR.mcNITOR 
if  i<end  of  file  found  instead  of  NUM.IN.NEXT>;  then 
exit  do 
end  if 

do  for  I  •  I  to  NUM.IN.NEXT 

accept  (NEXT.OBUECTSt I ) i  from  SaDAR.MONITOR 
end  do 

<for  each  object  described  b^  NCXT.0BUECT5>  see  if  the  altitude  has 
changed  compared  to  the  same  object  described  in  CURRENT.QBUCCTS  and 
save  indicator  of  altitude  change  of  object  in  record  NEXT.DCuECT ( I ) > 
<check  whether  ang  objects  are  too  close  to  each  other,  saving  an  indicator 
of  the  safety  of  each  object  in  the  NEXT.OBUECTs  records> 

<erase  the  screen  on  the  display  CRT> 

<for  each  object  described  NEXT.3CUECTS.  update  the  object  display  on  the 
display  CRT> 

CURRENT.OBJCCTS  •  NEXT.OBUECTS 
end  do 

end  SCREEN.UPDATE 

begin 

start  CONTROL 
end 
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4*C 

e^»•  SZCNAL  It  MOCtCfi'^tNXSXCe.  fCAdCH.OONC* 

«««k  RCM«r.M«#iOLfi( 

4«cl«r« 

(.NunjkCvf.iMCH.ro  tNrc4CH 
»cvt<9>  tmtNda  fo^ 

«vi«t  L  <4««c^t9ttan  •#  •r«4raA><  to 
ttooiit  (<fl4oroto*  to  cofietftuo>i  te  t«r<«taoi 
to  tortvor 

cfCArtitCAiiCH.  fc^CH.to- 
ooeoot  (MOCCCO)  *r^s  fCnACH 

•  tooiot  <<ooorotot  to  cootiruo  ar)4ro«>)  te  tt^^i^'o. 

1#  t<oflO  oO  ttlo  ^OCOtvOO>>  tRoo 
Otkt  00 
01*0  tO 

too  to 

lOo^  tvoo^  SCMCH  £foot«o.  octoot  *^tN(5nCC)  ^^o«  I^MCh> 

ooo  nc^rr.NONOccf 

took  SCAOCH 
toe iooo 

NUHjkCVf.  OCV.LtMdTH<?l.  I  At tNT^tO.  CATA.gAfC.CwaCC  >iTtft€« 

»<yfv9)  fTNCNCci  fO* 

^ILC.NtoC  fTftNOd  A0> 

•  ootn 

Nun.ikCvf  ■  0 

to  #oyowoo 

OfOAOt  (Cooototot  «C«C'MjHjP>C\f*l>  »  to  tOftitnol 
><ooo  0^  *tlo  ^oeOkvoo)  ttioA 
oitt  to 
ooo  lO 

Nun.itcySfltMt.ocyt«  i 

ooo  oo 

ooonot  (<oooootor  to  ootoo  ott  OAro.iAfC.CHOtCO  to  tot«»nol 
tOAO  (MOCCCO)  to  ACOUCSr.MAHOUCft 

<«Mtt  *O0  tIfAOl  ^OOA  OOOtOOO  KAACH  tkfOollAf  tOOt  it  it  tOOO.  i% 

Ooootof  0  Iloo  *00  toto  CKaACH  to  taoo  lA  totkovAieotiAf  •ltd  ^tt 
A(ltMr.rtCC  000<000> 

CfCATC  (MtMT  OtLC.  AftNT  ;0> 
tooo  (MOCCCOI  to  A«(Nr.#tLC 
oo  *00  t  •  t.NUHjtCVf 

tOAO  (ACVf((M  to  AfCNr.rtUC 
ACVjwCMOTMi  ()  O  ukfr.CMM.s^<oC«i't>. 
ooo  oo 

tooo  «-o«W»  to  AflNT.rjuc 

<OOOA  00001*100  40to  Ooto  tiA^etOO^  *%f> 

oo  Oooovoo 

<■000  t^tLC.NAHC)  *00tl  i(AO<tOd«| 

I*  <<OA0  0*  *VlO  ^0<0»v«0>  tdOA 

•lit  OO 
•no  I* 

I*  <OLk  MCVf  (N  ^lUCtriLC  SAI^.NIjrjOCVf.  ACvf.»C^  enon 

•ono  (^lkC«NA*«>  to  OfCNT^ritS 
•no  I* 

onO  00 

tono  fOCTtf*)  to  AflNr.OicC 

<1*  noooooooo*  Aott*<4  nokt  ^AfCH  toot  toit  ono  ;t  »»v«inot|At> 

••no  (CtNifMOt  to  tcaucir.  ;anou» 

•no  iCAllCH 

took  MtNT^XLK 

ooolooo 

ncvi  fTRtMfd  toi  •  n<fll 

9Tfl|N0<l  OQl  •  n«il 

•  OflA 

ooooot  (MOCCtPi  *oo«  Kaucu 
<000000  OoOOwt  *llo  "Tflt  WAfCM  &Af'  » 

00  vOltO  (MCVM  9l  /<■  Of  TOP  I 

OCOOft  (ACVI  *••«  «*>ACM 
votoo  (ncv)  to  *riiTjtorei«  oat* 

•no  Oo 
oo  oOkto 

ocioot  <^tUJKjtOHI>  *oo«  IMCh 
•otto  <rtuj'0^>  to  -TCHrjOAfCH  CAT- 

•no  Oo 

•no  Mtirr.FiU 

Oofin 

•toot  MfUHT JUOtCW 
•no  TKxr.f|MKH 
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€!<••  StONAL  i«  tENdUCUC' 
e4«k  •COuCIT.manDLCR 

:.NMn>cv<.  8c*«ch  to.  data  8Aic  chc::c  >rc^f( 

«cvt<9>  87RtNi<i  40' 

«PI»*  ( »ro^rA*>  ti 

0pa««t  '<o00v‘««of‘  ta  eaaeinu«)>  cc  rarAiisa; 

>10  ^orovor 
NUM.ACVt  ■  0 
4«  ^Ofavar 

ora«t«  <<aoarata^  *ae  ACVt«NUM^»Cvi<»i>  »a  tomfo; 

( <afi4  ail  ^tta  racai«aa)  ^nor 

out  4a 
alaa 

MUN.ACVf  .•iCVf  *  l 

•aa  1# 

ana  aa 

0no«a«  Uaaafacan  ta  ontar  him  C**a_5a8Cj:i<j:C£>  ee  tor.iral 

CUCArtiKAffO*.  iCA«CM_:C 

«ana  «QArA.|ACCj:HatCC.  ?o  tfAACH 

<tan4  i«CVfn>  nCvStNUA_»CvS»  •  to  £fiAACH> 

afa4aa«  <<aaanalar  ta  can*^i*wa  »r.{raA>'  to  to^'^ira. 

1#  > <ana  a4  4ii«  ra<Oi^aa>>  taoA 
aiit  4a 
ana  i* 

•na  la 

ana  KMIT^mANOLCA 

taat  auCUC.MAMhCCIi 
aac lana 

ffCttUCST  IIQNAL 

A«WT.{0.*Mt.a€yf.  :.!*£»  :>s.T6ft£f 

nCV.  rtLC.NA0«  fimtNCil  40' 
aafin 

aa  larawan 

aceoat  (ACOUCtT)  i*a« 
i4  (NCMtr  •  CNOUCUO  tnan 

C9CATf  (MtNT^lLC.  AWINT^IC  • 

iaccaat  NUPl.nCVf.  ana  cna  •#«  *C>«  **jm  «  SCaacn  arocttt  ana 

•ana  tna«  ta  tao  o^c^aat  tnat  <«ai  .i,**:  e^aatoa> 

<accaat  f«^.rtuCf.  ana  tn#  tat  ea  'tuC.*<AACt  tnw  SMCa  efocatt 

ana  tana  taaai  ta  tna  n<iti«r^At<»C  0ra€a«t> 
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